I am not sure about the state of _deferred after the move. Acording to https://stackoverflow.com/questions/13680587/move-semantic-with-stdfunction it will be in an unspecified state, that might not be empty.
If subscription is detached and then canceled it might call the detached funciton?

It says "Unless otherwise specified" -- meaning if a move constructor or operator was not defined. In the case of std::function, it is defined. It is true that, up to C++20, it is not guaranteed to be valid. But this is tested in the unit-test. And between us, we know it resets to nothing...

void _Reset_move(_Func_class&& _Right) noexcept { // move _Right's stored object
        if (!_Right._Empty()) {
            if (_Right._Local()) { // move and tidy
                _Set(_Right._Getimpl()->_Move(&_Mystorage));
                _Right._Tidy();
            } else { // steal from _Right
                _Set(_Right._Getimpl());
                _Right._Set(nullptr);
            }
        }
    }
function(function&& _Right) noexcept {
        this->_Reset_move(_STD move(_Right));
    }

Anyway, if this is a problem then it's a problem in deferred which was there before too. Let's talk?

If subscription is detached and then canceled it might call the detached funciton?

A detach will do _d.detach(), meaning _d should now be nothing. If you then cancel() then _d is nothing and nothing should happen. Right?

I'll make sure this is covered in the unit-test.

Consider adding a "notify" method, enabling calling the deffered function not only on destruction.

That's what cancel() is... right?

cancel() is one time only because it detaches the function

You want to call it multiple times?
Then you can detach and store it elsewhere. The whole point of a subscription is that the unsubscribe action happens once and only once...

Why do we want to keep order of calls? We should not rely on it when using a general utility.
We might not be able to guarantee this if moving to other implementations, e.g. boost.

Because it's general-purpose is exactly why I wanted to keep the order.
If the order is non-deterministic, then the function (result of using all the callbacks) isn't deterministic. E.g., the unit-test actually has a callback that gets an std::string & argument -- it actually changes the output value. The caller decides the functionality of the callbacks, and therefore losing determinism is not a good thing IMO. It doesn't cost much, either.

We might not be able to guarantee this if moving to other implementations, e.g. boost.

That's true. I actually implemented using vector<>. It was faster to create and run the signals. And you're right, it would have been harder to make it deterministic, though possible. The problem was the complexity. In the end I chose to go back to a map<> implementation because of its straightforwardness. It's good enough for our needs.

We're not likely to change the implementation. And if we do, it's better if we ensure determinism then, too.

Can you subscribe callbacks that receive arguments? subscription is using defered::fn which does not receive any

That's the beauty of it: a subscription doesn't have to know anything about what it's unsubscribing. It doesn't even have to work with signal -- you can have anything return a subscription.

The "callback" that goes into a subscription is always without arguments -- it has to be called from a destructor. if you want to pass stuff in, you do it thru the lambda, like signal does it.

OK, I get it now.
Maybe the name subscription is not the best, as it is not like a subscription to a publisher. It is only a one time call to a function, suitable to be used as a deleter.

Right, a subscription is just a deferred function but with different semantics: one main difference is the operator=() calling cancel().

Think of it like a subscription in English, not a subscription in the context of publisher-subscriber.

I am not too sure about what are the benefits of using a subscription over a deferred function though

The semantics.
Deferred will not cancel() on assignment.
Deferred has no cancel().
deferred is a good utility to have. subscription is a use-case with its own set of requirements..

Now that list->device is a shared_ptr and not an object shouldn't we test that is is not empty before dereferencing?
Same for other places in the file

It was a shared_ptr before, too -- just contained inside list->dev.device